Diseñando el sistema (página 2)

Partes: 1, 2

2. Arquitectura (1)
Definición, estilos y evaluación:

Primer nivel de descomposición, que muestra como se organiza el sistema en términos de sus componentes y las interacciones entre ellos.
Cambiar la Arquitectura de un producto ya construido en general exige mucho esfuerzo
=> Evaluación de Arquitecturas
Distintos “estilos” que definen familias de sistemas en términos de patrones de organización estructural.
Un estilo de arquitectura implica sus componentes, conectores y exigencias al combinarlos.
Identificarlos y caracterizarlos para facilitar la comunicación entre diseñadores

2. Arquitectura (2)
Influencia y características:

Sus características condicionan las características del producto final (escalabilidad, capacidad, desempeño, consistencia, mantenibilidad, compatibilidad, etc.)
Estilo y estructura particular elegidos pueden depender de Requerimientos No Funcionales:
1 – Desempeño: localizar operaciones críticas en un número reducido de subsistemas con poca comunicación. Componentes de grano grueso.

2 – Seguridad: estructurar en capas con los recursos más críticos protegidos por las capas más internas con alto nivel de validación.

3 – Mantenibilidad: componentes autocontenidos que puedan ser intercambiados con facilidad, evitando estructuras de datos compartidas. Componentes de grano fino.

CONFLICTO DE INTERESES: entre los requerimientos 1 y 3, si se tienen ambos se deberá buscar una solución intermedia.

2. Arquitectura (3)
Elementos para la documentación:

SAD (Software Architecture Description) salida del proceso de diseño de arquitectura, donde se incluyen modelos gráficos que muestran perspectivas distintas del sistema y descripciones textuales.
Documentarla para que pueda ser utilizada y mantenida por otros, con suficiente detalle, sin ambiguedades ni repeticiones, registrando decisiones tomadas.
Notaciones: UML general, accesible.
ADL’s formales, para expertos.
Complejidad se maneja documentando diferentes vistas de la arq., proyección en una dimensión mostrada desde una perspectiva, sin tener en cuenta entidades no relevantes a esa perspectiva.

The “4+1” View Model of Software Architecture – Kruchten’95
Vistas definidas: lógica, procesos, implementación, física y CU. Todas son guiadas por los CU (o escenarios) significativos a la arquitectura

Beneficios esperados de prestarle atención:

Mejorar la comunicación entre los distintos interesados:
Cliente – diseñadores
Diseñadores – desarrolladores
Clarificar intenciones de diseño
la arquitectura concebida a menudo se pierde, comunicación en gral. informal (difícil)
Proporcionar bases para análisis del diseño
predecir desempeño y otras características y ajustar el diseño como tarea rutinaria
Mejorar el mantenimiento
gran parte del esfuerzo de mantenimiento se dedica a entender
Identificar cuestiones interesantes
incluso careciendo de métodos formales
2. Arquitectura (4)

Métodos para evaluación de arquitecturas:

Analizar la arquitectura para ver si cumple requisitos de calidad establecidos (ej. confiabilidad, interoperabilidad)
Preferible realizar evaluaciones tempranas que permitan introducir cambios con menor impacto y mejorar los aspectos de riesgo identificados
Evaluaciones a posteriori resultan útiles como forma de aprendizaje y estudio de posibilidades de mejora, por ej. para una nueva versión del producto
Software Engineering Institute (SEI) propone:
Architecture Tradeoff Analysis Method (ATAM)
Software Architecture Analysis Method (SAAM)
2. Arquitectura (5)

Diseño: Arquitectura vs. Programas
(Gp:) Implementaciones de partes
(Gp:) Interacciones entre partes
(Gp:) Muestra
(Gp:) Copia de código o llamado a bibliotecas
(Gp:) Composición de subsistemas
(Gp:) Reutilización
(Gp:) Dentro de los límites de módulo
(Gp:) Fuera de los límites de módulo
(Gp:) Visión
(Gp:) Desempeño de algoritmos
(Gp:) Desempeño a nivel del Sistema
(Gp:) Evaluación
(Gp:) En general dinámico
(Gp:) En general estático
(Gp:) Análisis
(Gp:) Propiedades computacionales
(Gp:) Propiedades estructurales
(Gp:) Considera
(Gp:) Programas
(Gp:) Arquitectura

Arquitectura–Estilos (Garlan&Shaw, Sommerville,otros)
Flujo de Datos
Secuencial por lotes / Tubos y Filtros/ Circuitos de Control
Llamada y Retorno
Programa Principal y subrutinas / Orientada a Objetos
Componentes Independientes
Procesos que se comunican / Invocación implícita (Eventos)
Centrado en los Datos (repositorios)
Bases de Datos / Pizarrones (Blackboards)
Máquinas Virtuales
Intérpretes / Capas Jerárquicas
Específicas del Dominio de Aplicación
Modelos genéricos / Modelos de referencia
Distribuidas
Cliente-Servidor/ Objetos Dists. / Dist. Procesos, datos / SOAs
Heterogéneas y Otras

1 – Flujo de Datos
Caracterizadas por:
La disponibilidad de los datos controla la ejecución
La estructura del diseño está dominada por el movimiento ordenado de los datos de un componente a otro
El patrón del flujo de datos es explícito
En un sistema puro no hay otra interacción entre procesos
Ejemplos:
Secuencial por lotes (dominada por actualización de BD)
Tubos y Filtros – Filtros conectados en un grafo de flujo de datos
Circuitos de Control de Procesos

Tubos y Filtros (1)
Características:
Por los tubos fluyen datos, transmisión de salidas de un filtro a la entrada de otro
Cada filtro admite una o varias entradas (tubos) y una o varias salidas (tubos)
Cada filtro es independiente del resto y no conocen la identidad de los filtros antes y después de él
La transformación del filtro puede comenzar antes de terminar de leer la entrada (distinto al proceso por lotes)
Respetando el grafo, no importa la secuencia (paralelismo)

Ejemplo: pipelines (Unix)

Filtro
Tubo

Tubos y Filtros (2)
Bondades:
Fácil comprender el comportamiento total de entrada/salida del sistema a partir de los efectos de cada filtro
(entrada->transformación->salida)
Permite reutilización (simplicidad de interfaces, filtros reutilizables)
Fácil evolución y mantenimiento (agregar, sustituir, eliminar filtros)
Permite evaluar desempeño (independencia de filtros)
Permite ejecución en paralelo

Limitaciones:
Orientado a procesamiento por lotes (no interactivo)
Necesidad de consistencia entre flujos de datos
La independencia entre filtros puede acarrear la repetición de procesos de preparación (ineficiencias)
(ej. validaciones)

Circuitos de Control (de Procesos) (1)
Propósito:
Proveer control dinámico de un entorno físico. Ej. sist. acond. ambiental
Mantener propiedades específicas de las salidas del proceso dentro o cerca de valores de referencia indicados (puntos fijos o referencias)
Elementos a considerar:
Variables a monitorear, sensores a utilizar, su calibración, temporización tanto del sensado como del control.
Clasificación:
Bucle con retroalimentación (feedback loop)
Mide la variable controlada y ajusta el proceso para mantener el valor cerca o dentro de la referencia.
Bucle con prealimentación o anticipador (feedforward loop)
Mide otras variables del proceso que actúan como indicadores e intenta anticipar los futuros efectos sobre la variable controlada.

Circuitos de Control (de Procesos) (2)
Proceso
Controlador
variables de Entrada
Punto de
fijación
Variable
Controlada
Cambios en las
variables manipuladas
Bucle con retroalimentación (feedback loop):
Bucle anticipador (feedforward loop):
variables de Entrada
Punto de
fijación
Controlador
Cambios en las
variables manipuladas
Variable
Controlada
Proceso

Flujo de Control vs. Flujo de Datos
Flujo de Control:
La cuestión dominante es cómo se mueve el control a través del programa
los datos pueden acompañar el control pero no son dominantes
el razonamiento se refiere al orden de ejecución

Flujo de Datos:
La cuestión dominante es cómo los datos se mueven a través de un conjunto de procesos atómicos
a medida que se mueven los datos se activa el control
el razonamiento se refiere a la disponibilidad de los datos, su transformación, las demoras

2 – Llamada y retorno
Programa Principal y Subrutinas:
Descomposición Funcional tradicional
Orientada a Objetos (tipos abstractos de datos)
Ocultamiento de Información, especialmente de representaciones
Otros
Capas Jerárquicas
Sistemas Cliente/Servidor
Remote Procedure Call

Programa Principal y Subrutinas (1)
Características:
Descomposición jerárquica:
basada en la relación “usa”
Único Hilo de Control (Thread of Control)
soportado directamente por los lenguajes de programación
Estructura de subsistemas implícita
subrutinas agregadas en un módulo
Razonamiento jerárquico:
que una subrutina sea correcta depende de que sean correctas las subrutinas llamadas
Bondades:
Permite analizar los flujos de control y saber como responderá el sistema a cierto tipo de entradas
Limitaciones: Manejo de excepciones

Programa Principal y Subrutinas (2)
Principal
Subr. A
Subr.B
Subr.C
Subsistema
Llamado/Retorno

Orientada a Objetos (1)
Caracterizada por:
La solución está compuesta por un conjunto de agentes que interactúan
Representación de datos y operaciones asociadas se encapsulan en un objeto o TAD.
Herencia, Polimorfismo, Sobrecarga de operadores, enlace dinámico
Bondades:
Facilita el Mantenimiento (localización de impacto)
Promueve la reutilización de componentes
Permite cambiar la implementación de un objeto sin afectar al resto
Limitaciones:
Un objeto debe conocer las interfaces de aquellos que utiliza
Si se cambia una interfaz, se afectan todos los que la utilizan

Orientada a Objetos (2)
Llamado
Objeto

3 – Componentes Independientes
Procesos que se comunican
Pasan mensajes a los participantes conocidos
Sistemas guiados por eventos
Invocación implícita de participantes desconocidos
Otros
Envíos de mensajes múltiples con enlace dinámico

Procesos guiados por interrupciones
Controlador de interrupciones pasa el control a algún componente para su procesamiento

Procesos que se comunican (1)
Características:
Muestra al sistema como un conjunto de unidades ejecutando concurrentemente y sus interacciones.
Componentes: procesos independientes
típicamente implementados como tareas independientes
Conectados por: mensajes
punto a punto
asincrónicos y sincrónicos
RPC y otros protocolos se pueden construir encima
Ejemplos:
procesos que monitorean ejecución de otros procesos.

Procesos que se comunican (2)
Mensaje
Proceso

Invocación Implícita (guiada por eventos)
Caracterizada por:
Se registran procedimientos para los eventos
Un componente comunica un evento
Cuando se anuncia un evento los procedimientos asociados son invocados implícitamente
El orden de invocación es no determinista
Bondades:
Facilita la reutilización de componentes
Fácil cambiar los componentes que atienden un evento
Limitaciones:
No hay garantías respecto a qué va a pasar frente a un evento (quién responderá ni en que orden se dará la ejecución)
Limitaciones en la verificación (comprobar correctitud debido a dependencia del contexto y secuencia de eventos)
Ejemplos:
Depurador de programas que invoca uno u otro editor

4 – Centrados en los datos (repositorios)
Caracterizada por:
Hay un almacenamiento central de datos y un conjunto de componentes que operan sobre éste.

Bases de Datos transaccionales
gran almacén de datos central
orden de operación determinado por la entrada de datos
Pizarrón (blackboard)
representación central compartida adecuada a una aplicación
orden de operación determinado por estado actual de la estructura central
Otros
Herramientas CASE
Sistemas integrados de diseño

Pizarrón (Blackboard) (1)
Fuentes de Conocimiento
Procesos independientes que corresponden a particiones del conocimiento del mundo y del dominio dependientes de la aplicación
Responden a cambios en el pizarrón
Estructura de datos del Pizarrón
Estado completo de la solución del problema
Jerarquía de datos de estado para resolver el problema
único medio por el cual las Fuentes de conocimiento interactúan para llegar a la solución
Control
Guíado enteramente por el estado del pizarrón
Las Fuentes de conocimiento responden oportunamente cuando los cambios en el pizarrón aplican
Puede implementarse en las FC, en el pizarrón, en un componente separado o cualquier combinación de éstos.

Pizarrón (2)
Pizarrón
FC 1
FC 7
FC 6
FC 2
FC 3
FC 4
FC 5
Cálculos
Memoria (Compartida)

5 – Máquinas Virtuales
Intérpretes:
crean una máquina virtual cuando no se dispone de la que se desea
Capas Jerárquicas:
cada capa constituye una máquina virtual que provee servicios a las otras capas
Otros:
Sistemas basados en Reglas
tipo especial de intérpretes
procesadores de lenguaje de comandos
shells

Intérpretes (1)
Características:
procesador emulado por software
datos
representación del programa que se interpreta
estado del programa que se interpreta
estado interno del intérprete
El control reside en el ciclo de ejecución del intérprete

(Gp:) Datos
(estado del
programa)
(Gp:) Programa
siendo
interpretado
(Gp:) Estado
interno del
interprete
(Gp:) Motor de
interpretación
simulada
(Gp:) Memoria
(Gp:) entradas
(Gp:) salidas
(Gp:) Máquina de estado
de la ejecución
(Gp:) Instrucción seleccionada
(Gp:) Datos seleccionados
(Gp:) Acceso a datos
Recuperar/Almacenar

Intérpretes (2)

Capas Jerárquicas (1)
Caracterizada por:
Hay diversas capas, cada una provee un conjunto de servicios a las capas superiores y requiere servicios de las inferiores.
Modelo estricto: el acceso a servicios de otras capas está limitado, una capa sólo utiliza servicios de la inmediata inferior, y ofrece servicios a la inmediata superior. Sino Modelo relajado.
Definición de protocolos mediante los que interactúan las capas
Bondades:
Facilita la comprensión (basado en niveles de abstracción)
Facilita mantenimiento (posible modificar una capa sin afectar al resto)
Facilita reutilización
Facilita portabilidad
Limitaciones:
No siempre es fácil estructurar en capas ni identificar los niveles de abstracción a partir de los Requerimientos
Puede afectar el desempeño la coordinación entre los niveles

Capas Jerárquicas (2)
(Gp:) Usuarios
(Gp:) Criptografía
(Gp:) Interfaces de Archivos
(Gp:) Gestión de Claves
(Gp:) Autenticación

Ejemplo:
Capas de Sistema de Seguridad

6 – Específicas del dominio de aplicación
Modelos específicos para un dominio de aplicación particular
Modelos genéricos:
Abstracciones de sistemas existentes que encapsulan las características principales de los mismos. A menudo representan la arq. común de una familia de aplicaciones (línea de productos).
Ejs. Módulos que se deben incluir en un compilador
Modelos de referencia:
Modelos abstractos idealizados derivados de un estudio del dominio de aplicación. Proveen información sobre la estructura general del sistema y actúan como estándar contra el cual evaluar sistemas.
Ejs. Modelo de capas OSI para sists. de comunicación

7 – Distribuidas
Cliente-Servidor:
servicios provistos por los servidores y requeridos por los clientes
Objetos Distribuidos:
objetos brindan y requieren servicios de otros objetos
Service Oriented Architecture (SOA):
composición de servicios (ej. web-services)
Distribución de:
Datos (centralizados, distribuidos, replicados)
Procesos (fija, variable)
Comunicación:
Remote Procedure Call
Pasaje de mensajes

7 – Distribuidas
Características:
El procesamiento de la info es distribuído sobre varias computadoras (procesadores) conectados por una red
se requiere cierto software de “middleware” para administrar las partes y asegurar comunicación e intercambio de datos
el “middleware” es un software de propósito gral. que por lo regular se vende comercialmente, y actúa como mediador entre las partes
categorías de “middleware”: monitor transaccional (TPM), remote procedure call (RPC), message oriented mid.(MOM), distributed object mid., database access mid.
Bondades:
Compartición de recursos, apertura, concurrencia, escalabilidad, tolerancia a fallas, transparencia.
Limitaciones:
complejidad, seguridad, difíciles de gestionar, poco predecibles

Cliente – Servidor
Caracterizada por:
hay un conjunto de servicios provistos por los servidores y un conjunto de clientes que requieren esos servicios.
Los clientes conocen a los servidores pero no a otros clientes y los servidores no tienen porque conocer a los clientes
tanto los clientes como los servidores son procesos lógicos
la asignación de procesos a procesadores no tiene porqué ser 1:1
Ejemplo:
Ci = clientes
Si = servidores

Cliente – Servidor en 2 niveles
Organización más simple de la distribución C/S, un conjunto de clientes y un servidor (o varios servidores idénticos):
CLIENTE FINO:
el procesamiento de la aplicación y manejo de los datos se hace en el servidor. El software en el cliente implementa solo la presentación
Gran carga de procesamiento tanto en el servidor como en la red
CLIENTE GRUESO:
el servidor solo es responsable por el manejo de los datos. El software en el cliente implementa la lógica de la aplicación y las interacciones con el usuario.
Administración del sistema más compleja (actualizaciones)

Los applets descargables de Java permiten:
Parte del software de procesamiento de la aplicación se descarga en el cliente como applets de Java, la interfaz de usuario se construye utilizando un navegador Web que los ejecuta

3 niveles:
Los procesos lógicos que tienen que ver con la presentación, lógica de aplicación y administración de datos pueden ser distribuídos en 3 sistemas de cómputo distintos.
N niveles:
Se amplía la de 3 niveles agregando niveles según se requiera. Ej. aplicación que necesita acceder y utilizar datos de distintas fuentes (integración)
Bondades:
Respecto a C/S en 2 niveles: son más escalables, se reduce el tráfico en la red (respecto a cliente fino), facilita la actualización del procesamiento de la aplicación (respecto a cliente grueso)

Cliente – Servidor en 3 y más niveles

Objetos distribuidos
Características:
No hay distinción entre clientes y servidores
Cada elemento distribuido es un objeto que provee servicios a otros objetos y requiere servicios de otros objetos.
Comunicación entre objetos es a través de un middleware llamado Object Request Broker (software bus) ej. CORBA
Más complejos de diseñar que los sistemas C/S
Ejemplo:

Service Oriented Architecture (SOA)
Características:
Funcionalidades expuestas como servicios independientes mediante interfaces públicas bien definidas
Procesos del negocio se realizan estableciendo secuencias (coreografías) de invocación de éstas funcionalidades
Implementación con web-services brinda mayor interoperabilidad, utilización de protocolos estándares de comunicación e intercambio de información (SOAP, XML)
Funcionamiento gral.:

Motivación: Costo de un acceso remoto en una red super-rápida es aprox. 4 veces el costo de un acceso local.
Soluciones:
Distribuir los datos en varias máquinas según cercanía a quienes más los acceden, el todo es la suma de las partes.
Replicar los datos en varias máquinas (caso extremo en cada una) de forma que los accesos sean mayormente locales. Se debe mantener consistencia de las copias

Distribución de Datos
Distribución de Procesos
Puede ser estática o dinámica:
Estática: está predefinido donde se ejecutará cada proceso
Dinámica: la distribución de procesos se establece en tiempo de ejecución ? permite migración de procesos

Remote Procedure Call:
Llamada retorno entre módulos en distintas máquinas.
Aspectos a tener en cuenta: pasaje de parámetros (distintos espacios de memoria), manejo de excepciones.

Pasaje de mensajes:
Cada módulo recibe mensajes de otros, los procesa y responde al módulo apropiado.
Aspectos a tener en cuenta: cantidad de mensajes que se pueden recibir.

Ambos paradigmas son iguales en capacidades, uno puede simularse con el otro. RPC inherentemente sincrónico y pasaje de mensajes asincrónico.

Comunicación

8 – Heterogéneas y Otras
Combinación de varios de los estilos vistos anteriormente

Distintas formas de realizar esta combinación:
Jerárquicamente: un componente organizado en un estilo puede tener estructura interna desarrollada en otro estilo. Ej. Tubos y filtros y cada filtro con otro estilo.

Mezcla de conectores: un componente puede utilizar distintos estilos de conectores para interactuar con distintas partes del sistema. Ej. un componente accede a un repositorio a través de parte de su interface pero interactúa a través de tubos con otros componentes.

Otras: clasificación no cerrada, pueden haber otros estilos, pueden clasificarse en forma distinta ……

3. Técnicas y Herramientas
Concurrencia
Interfaz de Usuario
Principios para guiar el Diseño
Modelo de Análisis de Jacobson
Tarjetas CRC
Diagramas UML
Patrones de Diseño
Marcos de trabajo (Frameworks)
Model Driven Development / Architecture (MDD – MDA)
Desarrollo basado en componentes

Procesos Concurrentes
Control de Acceso a Recursos Compartidos
Exclusión mutua (Prueba y Bloqueo en una operación indivisible)
Guardián (un “demonio” que acepta requerimientos si el recurso está disponible)
Monitores (un objeto abstracto que exporta servicios garantizando exclusión)
Tiempo Real
Procesos Concurrentes + tiempo crítico
Según gravedad de no suministrar servicio en el plazo:
Soft – operación se degrada si no se cumplen los reqs. de tiempo (ej: central telefónica)
Hard – operación es incorrecta si no se cumplen los reqs. de tiempo (ej: central nuclear)

Complejidad en el diseño
Sist. Secuencial tiempo solo
Sist. Concurrente afecta performance
Sist. Tiempo Real
Soft tiempo también
Hard afecta correctitud

Los Sists. de Tiempo Real en gral. interactúan con ambiente externo que produce estímulos en forma autónoma a los cuales el software debe responder en un tiempo límite establecido.

Diseño de la Interfaz de Usuario (1)
Principios generales (Sommerville)
Familiaridad: utilizar términos familiares a los usuarios
Consistencia: menúes y comandos con el mismo formato y significado en toda la aplicación
Mínima sorpresa: misma acción en contextos comparables produzcan un cambio similar
Recuperabilidad: recuperación frente a errores cometidos por el usuario, brindar:
confirmación de acciones destructivas
recursos para deshacer en varios niveles
Guía al usuario: proveer ayuda en varios niveles
Diversidad de usuarios: tener en cuenta distintos tipos de usuarios.

Diseño de la Interfaz de Usuario (2)
Elementos Claves (Pfleeger):
Metáforas: imágenes fundamentales y conceptos
Modelo del método: la organización y representación de la información
Reglas de navegación para el modelo: cómo moverse y el modelo espacial
Apariencia: transmite información y significado para los usuarios
Sensación: la que proporciona experimentar las técnicas de interacción

Color en el diseño de la Interfaz (1)
Lineamientos clave (Shneiderman 1998)
Limitar cantidad de colores utilizados, no más de cuatro o cinco colores distintos por ventana
Utilizar un cambio de color para indicar un cambio en el estado del sistema
Utilizar el código de colores para apoyar tarea de usuarios, por ej. resaltar similitudes o diferencias
Utilizar el código de colores en forma consistente, por ej. desplegar mensajes de error en rojo siempre!
Tener cuidado al combinar colores que puedan producir cansancio en la vista

Color en el diseño de la Interfaz (2)
Elementos culturales
¿Qué color utilizar? ¿Púrpura?
En Inglaterra representa la realeza
En Japón, dignidad y nobleza
En Grecia representaba al diablo y la muerte
Dos pasos para hacer nuestros sistemas multi-culturales
(1) eliminar sesgos o referencias a una cultura específica
(2) ajustar (1) para las culturas que utilizarán el software

Preferencias de Usuario
A ella le gusta, a él no…
No hay una interfaz universal aplicable a todo el mundo
construir un prototipo y evaluarlo con la audiencia objetivo
permitir adaptar la interfaz de usuario
ejemplo: Microsoft Word vs. WordPerfect

Guía para definir la interfaz de usuario
Facilidad de Uso
Alto

Medio

Bajo
Entrada de datos
Reconocimiento Línea de Formu- Pantalla OCR
de Voz Comandos larios sensible optical character
al tacto recognition

Soporte al Usuario
Sistema de ayuda debe proveer:
Mensajes de error
Amables, concisos, consistentes y constructivos, si es posible incluir sugerencia para correción
Ayuda en línea
Páginas web con hipervinculos, ventanas múltiples
Cuidar la estructura de navegación, si es compleja los usuarios se pierden
Documentación de usuario
Incluyendo secciones de: instalación, descripción general, descripción funcional, mensajes de error.

Mensajes de error
Err
or #27
Identificador de paciente no válido
?
El paciente J. Bates no está registrado

Seleccione:
Pacientes para listado de pacientes registrados
Reintentar para reingresar el nombre del paciente
Ayuda para más información
Pacientes
Mensaje orientado al sistema
Mensaje orientado al usuario
Ayuda
Reintentar
Cancelar
Aceptar
Cancelar

Diseño – Principios
Diseño para el Cambio
Separación de Intereses
Modularización (localización del impacto de los cambios)
Niveles de Abstracción (facilita comprensión)
Ocultamiento de Información (encapsular)
Alta Cohesión, Bajo Acoplamiento

Diseño para el cambio
¿Qué puede cambiar?
Algoritmos
requerimientos de desempeño, escala
Representación de los datos
requerimientos de desempeño, escala
cambios en interfaces
equipos externos
ambiente social
Para reducir el impacto de los cambios: Modularizar

Modularización (1)
Módulo: un componente bien definido de un sistema de software que provee recursos y servicios
Están bien definidos:
Recursos y Servicios
La forma de suministrarlos (Interfaces)
Un módulo puede ser un programa o varios, una subrutina o varias
Principio de Separación de Intereses
cada módulo se ocupa de aspectos específicos

Modularización (2)
Definir módulos e interfaces
Interfaces definen el acoplamiento entre módulos
Comportamiento (Pre-Post condiciones) y colaboraciones
Ocultamiento de Información
La información de un módulo debe ser privada a menos que se declare pública, única garantía de que otros módulos no la utilicen ( – impacto de cambios, + fácil de comprender y usar)
Diseño interfaz:¿Qué servicios brindar, qué ocultar?
Mínima, bien definida, independiente de implementación
Alta Cohesión – Bajo acoplamiento
Alta cohesión interna de cada módulo (los elementos del módulo están fuertemente relacionados entre sí)
Bajo acoplamiento entre módulos (débiles conexiones entre módulos -impacto reducido de cambios)

Categorías de módulos
Sin persistencia (estado)
Abstracciones de procedimientos (algoritmo)
Bibliotecas (ej. rutinas matemáticas)
Sólo Datos
Repositorio común de datos (ej. Configuración)
Algoritmos + Estado
Objetos abstractos (ej. Stack)
Tipos Abstractos de Datos
paramétrico en tipo (ej. Stack (?) )
Clases (OO)

Criterios para modularizar
Descomposición
Descomponer el problema en sub-problemas (diseño top-down)
Composición
A partir de los componentes es posible obtener un nuevo sistema (diseño bottom-up)
Continuidad del impacto por cambios
Pequeños cambios en la especificación afectan pocos módulos
Protección durante ejecución
Efectos de anomalías durante la ejecución están localizados

Principio Abierto/Cerrado
“los módulos debieran ser a la vez abiertos y cerrrados”
Abierto para permitir extensiones
Agregar operaciones o atributos para extender el comportamiento
Cambiar representaciones internas e implementaciones en caso necesario
Cerrado para permitir ser usado por otros módulos
La interfaz debe mantenerse cerrada a los cambios y asegurar que se mantiene el comportamiento (pre- y post-condiciones)

Principio de elección única
Cuando un sistema de software debe soportar un conjunto de alternativas, un módulo y sólo uno debe conocer la lista completa de alternativas
Minimiza
Código a escribir
Impacto de cambios en la lista
Reduce la complejidad y por lo tanto facilita comprensión
En general, se debe minimizar la distribución de conocimiento

Modularización – Beneficios
Separar aspectos del diseño
Permitir cambiar algunos sin afectar al resto
Permite
Extender fácilmente artefactos (extensibilidad)
Reusar artefactos existentes (reusabilidad)
Ocultar dependencias de la plataforma (portabilidad)
Diseñar interfaces que se adapten a otras (compatibilidad)
Minimizar impacto de cambios (mantenibilidad)
Facilitar la comprensión
Organizar y distribuir el trabajo
Alta modularización => Alta cohesión – Bajo acoplamiento

Cohesión
Coincidente (no relacionados)
Lógica (tipo de función)
Temporal (se usan en el mismo momento)
de Procedimiento (asegurar el orden de ejecución)
de Comunicación (operan sobre o generan los mismos datos)
Secuencial (salida de una parte es entrada de otra)
Funcional (cada parte es esencial para cumplir una función)
de Información (TAD – extensión para OO)

Cohesión Coincidente
Poca o ninguna relación entre los elementos de un módulo
Dificulta el mantenimiento
Módulos no reusables
Manifestaciones en el caso de OO
Clase no representa un único concepto OO
Conjunto de código usado frecuentemente como una clase con herencia múltiple

Cohesión Lógica
El módulo cumple varias funciones relacionadas. Al invocar al módulo se debe indicar mediante un parámetro qué función llevar a cabo
Interfaz difícil de entender
El código para más de una función puede entremezclado
Difícil de reusar
Solución:
Aislar cada función en operaciones separadas

Cohesión Temporal
Los elementos del módulo están agrupados porque se usan en el mismo período
No reusable
Ejemplo:
Módulo que concentra la inicialización de valores a objetos
Módulos que se encargan de limpiar al fin de un trabajo

Cohesión de Procedimiento
Los elementos del módulo están agrupados sobre la base de participar en un proceso o algoritmo
Específicos para una aplicación
Difícilmente reusable
En el contexto el módulo es razonable, pero difícil de entender fuera de este
Solución:
Rediseñar

Cohesión de Comunicación
Los elementos del módulo usan y/o generan el mismo conjunto de datos
Difícilmente reusable
Solución:
Aislar cada elemento en módulos separados

Cohesión Funcional
Las operaciones de un módulo se pueden describir colectivamente como una única función
más reusable
Mantenimiento correctivo más fácil
En OO:
Cada operación de la interfaz pública debiera presentar cohesión funcional
Cada objeto debe representar un único concepto cohesivo

Cohesión de Información
Un módulo tiene cohesión de información si cumple varias funciones:
Varios puntos de entrada
Cada entrada desempeña una función específica
Todas las funciones están relacionadas por un concepto, estructura de datos, o recurso que el módulo oculta

Acoplamiento
Acoplamiento por Contenido
modificación de variable interna, ejecución de una porción de procedimiento
Area Común (cualquiera modifica)
De Control (No hay ocultamiento de información)
Parámetro (de entrada o salida) que gobierna ejecución
Estructura de Datos (comparten la estructura)
Datos (lo deseable) – mínima
No acoplado

Tarjetas CRC (1)
Clase – el nombre
Responsabilidades – lo que sabe y lo que hace
Collaboraciones – quiénes le ayudan
(Gp:) Clase: Model
(Gp:) Colaboradores:
View
Controller

(Gp:) Responsabilidad:
Proporciona el núcleo de funcionalidad de la aplicación
Registra los View y Controller dependientes
Notifica a los componentes dependientes acerca de cambios en los datos

Tarjetas CRC (2)
Permite una rápida visión de los elementos esenciales de las clases al encarar la descomposición
Se usan como técnica de diseño con participación de usuarios
Cada uno desempeña el rol de una clase
Cada uno describe lo que hace al “ejecutar” un determinado escenario de cierto caso de uso

Diagramas UML (1)
Paquetes (visión de alto nivel mostrando dependencias)
mecanismo para agrupación de elementos
la dependencia significa que cambios en uno afectan al otro
Subsistemas (visión de paquetes, comportamiento de clases)
agrupación lógica de elementos de diseño, con interface de servicios que brinda (implementados por las clases)
De Interacción (dos visiones distintas de lo mismo)
Secuencia (deja en claro la evolución temporal)
Comunicación (muestra más claramente las interacciones, pero el orden está dado por números)
Clases (relaciones estáticas, operaciones,navegabilidad)
Componentes (dependencias entre componentes)
Despliegue (Deployment del software en el hardware)

Diagramas UML (2)
Paquetes
Elemento de modelado que contiene otros elementos de modelado
como mecanismo de agrupación no tiene semántica definida
puede no tener representación en implementación (si tiene podría ser un directorio)
un paquete es dueño de sus elementos; un elemento pertenece a un solo paquete
el uso de paquetes fuerza a la modularidad

Diagramas UML (3)
Subsistemas
agrupación de elementos donde algunos constituyen la especificación del comportamiento ofrecido por otros elementos contenidos [Booch,1999]
elemento de modelado que tiene semántica package+clase que provee comportamiento
implementa una o más interfaces que definen el comportamiento del subsistema
un subsistema representa un componente en el diseño
el uso de subsistemas fuerza a la modularidad &encapsulación

Diagramas UML (4)
Componentes
describe la organización de los componentes físicos del sistema
un componente es la realización física de una abstracción en el diseño
los componentes corresponden a implementación
ejemplos de componentes son:
.exe, .dll, .java, .class
se pueden estereotipar como: < < source code>>, < < file>>, < < executable>>, entre otros.

Diagramas UML (5)
De Interacción: Secuencia
sobre un conjunto de objetos y sus relaciones, muestra la interacción entre éstos incluyendo los mensajes que intercambian
el orden de los mensajes se muestra en relación al tiempo
cada objeto tiene una línea de vida sobre la cual se muestran los bloques de activación (tiempo que el objeto necesita para completar una tarea)
se pueden modelar mensajes sincrónicos y asincrónicos, loops, entre otros.

Diagramas UML (6)
De Interacción:Comunicación
sobre un conjunto de objetos y sus relaciones, muestra la interacción entre éstos incluyendo los mensajes que intercambian
el orden de los mensajes se muestra numerado

los mensajes se pueden anidar mostrando la anidación con la numeración, se pueden modelar loops.
las asociaciones son las existentes entre los objetos en el diagrama de clases.

Diagramas UML (7)
Clases:
Muestra las clases en el sistema y como se relacionan
Información sobre atributos y tipos correspondientes, operaciones con paramétros y tipos correspondientes, multiplicidad de las asociaciones, agregación, composición, generalización.
Clases que pueden iniciar y controlar flujo de las actividades se recuadran en negritas (por ej. correspondiente a una clase de control para un CU)

Diagramas UML (8)
Deployment o despliegue
muestra los recursos físicos de un sistema incluyendo componentes, nodos y conexiones
presenta la distribución de componentes de software en nodos donde ejecutan, y las asociaciones entre los nodos
asociaciones representan conexiones físicas entre nodos estereotipadas por protocolos de la comunicación, ej. TCP/IP, HTTP.

Patrones de Diseño
“ Un patrón es una solución a un problema en un contexto” (Christopher Alexander) => Reuso y Diseminación
Surgen en la arquitectura (de casas) y los principios se aplicaron exitosamente a OOP.
Nombre del patrón. Hace posible referirse a él.
El problema. Un patrón particular es aplicable a ciertos tipos de problemas. Un aspecto relevante de la definición de un patrón es la descripción de para qué tipos de problemas es útil.
La solución. Un patrón define una solución conceptual particular al problema.
Consecuencias. Las decisiones de implementación implican ciertos compromisos. Las consecuencias de esas decisiones y las fuerzas que están por detrás del patrón son aspectos esenciales de este.

Patrones de Diseño para Sistemas Interactivos
Mecanismos complicados de GUI
Cambios y adaptaciones frecuentes
Múltiples estándares de apariencia
Funcionalidad Compleja
Usualmente permanece relativamente estable
El problema:
mantener la funcionalidad del núcleo independiente de Interfaz de Usuario
Patrones:
Model-View-Controller (MVC)
Presentation-Abstraction-Control (PAC)

Model-View-Controller (MVC)
Model
Núcleo de la Funcionalidad
View
Desplegar la Información
Controller
manejar la entrada de usuario

GUI
Datos del Núcleo
Ejemplo:

MVC – Fuerzas
La misma información se presenta distinto en diferentes ventanas
El despliegue y comportamiento de la aplicación debe reflejar inmediatamente las manipulaciones de los datos
Cambios a la IU debieran ser fáciles y posibles en tiempo de ejecución
Soportar distintos estándares de apariencia o portar la IU no debiera afectar el núcleo de la aplicación

MVC – Clases (1)
(Gp:) Clase: Model
(Gp:) Colaboradores:
View
Controller

(Gp:) Responsabilidad:
Proporciona el núcleo de funcionalidad de la aplicación
Registra los View y Controller dependientes
Notifica a los componentes dependientes acerca de cambios en los datos

Encapsula los datos, proporciona métodos de acceso para las vistas
“Controllers” invocan los métodos exportados para el procesamiento de la aplicación
El patrón “Observer” se puede usar para propagar los cambios

MVC – Clases (2)
(Gp:) Clase: View
(Gp:) Colaboradores:
Controller
Model

(Gp:) Responsabilidad:
Crea e inicializa su Controller asociado
Obtiene datos de Model
Despliega información al usuario
Implementa el procedimiento update

Cada View crea un Controller adecuado (uno a uno)
Ofrece interfaces que habilitan a Controller para algunas manipulaciones de despliegue que no afectan el modelo (p.e. scroll)

MVC – Clases (3)
(Gp:) Clase: Controller
(Gp:) Colaboradores:
View
Model

(Gp:) Responsabilidad:
Acepta entradas del usuario como eventos
Traduce eventos en solicitudes de servicio para Model o View
Si se precisa, implementa el procedimiento update

EL procedimiento update se implementa en caso de que el comportamiento de Controller depende del estado de Model (p.e. un cambio del modelo habilita o deshabilita un menú)

Diagrama de Clases

Distintas opciones Cliente/Servidor
Cliente
Servidor
Int.
Usuario
Int.
Usuario
Lógica
Aplic.
DBMS
Int.
Usuario
Lógica
Aplic.
DBMS
Interfaz distribuida
Aplic. Remota
(Gp:) Int.
Usuario
(Gp:) Lógica
Aplic.

Lógica
Aplic.
DBMS
Aplic. distribuida
(Gp:) Int.
Usuario
(Gp:) Lógica
Aplic.

(Gp:) DBMS

(Gp:) DBMS

Int.
Usuario
Lógica
Aplic.
DBMS
DBMS Remoto
DBMS distribuido

Patrones para Distribución
Además, se pueden tener otros niveles…
¿cuál es el costo de cambiar la forma de distribución?
¿cómo incide en el esfuerzo de desarrollo la comunicación entre los componentes?

Problema:
Componentes remotos debieran aparecer como locales
Cliente y Servidores no debieran preocuparse de la comunicación

Solución:
Un sustituto del servicio que permite el acceso local
Proxy
Cliente
(Gp:) Servicio Abstracto
(Gp:) servicio

(Gp:) Servicio
(Gp:) servicio

(Gp:) Proxy
(Gp:) servicio

No es directamente accesible al Cliente
1
1
Proxy representa al Servicio y asegura el acceso a él (misma interfaz)

Proxy – diagrama de secuencia
(Gp:) Cliente
(Gp:) Proxy
(Gp:) Servicio
(Gp:) servicio
(Gp:) servicio
(Gp:) Pre-proceso y asignación
(Gp:) Post-proceso y devolución

¿Cuántos proxys precisamos?
Problema:
Muchos servicios pueden ser remotos
Las ubicaciones de estos pueden cambiar
Se deben poder agregar, cambiar y suprimir servicios dinámicamente
Los detalles debieran quedar ocultos para el desarrollador

Broker
(Gp:) Broker
(Gp:) Proxy-Cliente
(Gp:) Servicio_p
(Gp:) Proxy-Servidor
(Gp:) Servicio Abstracto
(Gp:) Call_servicio_p
(Gp:) Servidor
(Gp:) Servicio_i
(Gp:) llama
(Gp:) llama
(Gp:) mensajes
(Gp:) mensajes

Solución:
Un intermediario entre proxys cliente y servidor

Broker – diagrama de secuencia

Marcos de trabajo (Frameworks) (1)
Aplicación reusable, semi-completa que puede ser especializada
Proporciona un esqueleto extensible
Soporta reuso del diseño y del código
Gran parte del esfuerzo y costo proviene de:
Redescubrir y reinventar el diseño de clases básicas y de sus interacciones
Clases de frameworks:
infraestructura de sistemas (ej. interfaces usuario Struts)
integración de middleware (ej. Corba, Com)
aplicaciones empresariales (ej. sists. Financieros)

Marcos de trabajo (Frameworks) (2)
Diferencias con otras bibliotecas de clases:
Principio de “inversión del control”
Basado en el patrón de diseño “template method
Captura las interacciones entre objetos en un “template method”, postergando algunos pasos (“hook methods”)
Especificando los “hook methods” los desarrolladores pueden ajustar las interacciones provistas por el framework
Son los “template methods” los que invocan a los “hook methods” => inversión del control

Marcos de trabajo (Frameworks) (3)
biblioteca
aplicación
Framework
Biblioteca de Clases
biblioteca
aplicación
Reescribiendo los “hook methods”el desarrollador inserta la personalización
Framework invoca “hook methods” como parte de su interacción
El desarrollador implementa las clases del núcleo y sus interacciones reusando funcionalidad ya existente
Conjunto de clases con funcionalidad preexistente

Marcos de trabajo (Frameworks) (4)
Problemas:
No existe metodología:
cómo desarrollarlos
Cómo usarlos
Curva de aprendizaje
En general lleva mucho tiempo y esfuerzo aprender a utilizar un marco de forma eficiente. Cuanto más complejo el marco, mayor es la curva de aprendizaje

Model Driven Development/Architecture (MDD – MDA) (1)
Enfoque de desarrollo basado en modelos
brinda significado al uso de modelos
dirigen el curso del: conocimiento, diseño, construcción, distribución, operación, mantenimiento y modificación del sw
MDA es un estándar bastante reciente del OMG (Object Management Group) (versión 1.0.1 junio 2003)
Principales objetivos de MDA
Portabilidad
Interoperabilidad
reusabilidad

Principales conceptos de MDA

Computation Independent Model
(= modelo de dominio)

Platform Independent Model
(funcionalidad y comportamiento del sistema, sin detalles de tecnología)

Platform Specific Model
(mapeo a diversas tecnologías de middleware, generado a partir del PIM, aplicando mapeos standard de la OMG. Código parcialmente autom.)
Model Driven Development/Architecture (MDD – MDA) (2)
(Gp:) CIM
(Gp:) PIM
(Gp:) PSM

Ejemplo de MDA
Modelo conceptual
UNICO

Modelo funcionalidad
y comportamiento
UNICO

PSM
(distintas
plataformas)
y
Deployment
Model Driven Development/Architecture (MDD – MDA) (3)
(Gp:) CIM
(Gp:) PIM
(Gp:) Modelo
Corba
(Gp:) Modelo
Java/EJB
(Gp:) Modelo
XML/SOAP
(Gp:) Otros Modelos
(Gp:) Corba
(Gp:) Java/EJB
(Gp:) XML/SOAP
(Gp:) Otros

Desarrollo basado en componentes (1)
Surgimiento a fines de los ’90, originado por el no cumplimiento de las expectativas de reutilización que había prometido el desarrollo OO, debido a:
Clases demasiado detalladas, específicas y ligadas a las aplicaciones
Muchas veces hacía necesario disponer del código fuente => dificultades en comercialización
Visión de componente: proveedor de servicios
Entidad ejecutable e independiente
Publica interfaz de servicios suministrados y las interacciones son a través de ésta
Generalmente también define interfaz de servicios que debe proveer el sistema que lo utiliza

Desarrollo basado en componentes (2)
Distintos niveles de abstracción (Meyer ’99)
Funcional: implementa una sola función (ej.matematica)
Agrupamiento casual: colección de entidades relacionadas débilmente (ej. declaraciones de datos, funciones)
Abstracciones de datos: abstracción o clase de datos en OO (crear, modificar, acceder)
Abstracciones de clúster: grupo de clases relacionadas que trabajan conjuntamente (también marcos de trabajo o frameworks)
Abstracciones de sistemas: sistema autocontenido (también COTS)

4. Características de un buen Diseño
Independencia de Componentes
Tratamiento de Anomalías
Prevención de Fallas

Independencia de componentes
Cuanto mayor es la independencia, más fácil es:
La comprensión
Mejorar, extender, adaptar, corregir
Mantenimiento
Medida de independencia (Myers, Constantine)
Cohesión: medida de cuán focalizado está el módulo en una cosa
Acoplamiento: medida de cuán conectado está el módulo con otros y con el ambiente
Se busca alta cohesión y bajo acoplamiento

Identificación y Tratamiento de Anomalías
Diseño defensivo
tratando de anticipar situaciones que podrían llevar a problemas en el sistema
Anomalías incluyen:
imposibilidad de brindar un servicio
proporcionar un servicio o datos incorrectos
corrupción de datos
Tratamiento:
Reintentar: restaurar e intentar nuevamente con estrategia distinta
Corregir: restaurar, corregir algo e intentar de nuevo con misma estrategia
Informar: de la imposibilidad a alguien, restaurar pero no intentar nuevamente

Prevención de Faltas y Tolerancia a Faltas
Tratar de anticipar faltas y manejarlas de forma de minimizar los efectos negativos y maximizar la seguridad

Falta: el error cometido por una persona se traduce en una falta en un producto de software (o productos)

Falla: desvío del sistema del comportamiento requerido

No toda falta produce una falla, las condiciones para que una falta resulte en falla pueden no producirse nunca

Prevenir o tolerar faltas para evitar fallas, construyendo el sistema para que reaccione de manera aceptable

Técnicas para evitar fallas (1)
Detección activa de faltas (antes de ser falla)
Periódicamente verificar síntomas de faltas, anticipar si van a ocurrir:
control de totales, dígitos verificadores (redundancia)
Sospecha mutua: cada componente verifica sus entradas, supone que los demás tienen defectos
Procesos independientes sincronizados: arquitectura especial, realizan en paralelo el mismo trabajo y comparan resultados continuamente
Ejecutar n versiones distintas del programa:
diseño y construcción independiente
con mecanismos de votación para decidir acción siguiente

Técnicas para evitar fallas (2)
Respuesta a la Falta Detectada:
Dependiendo de la criticidad del sistema, falta, requerimientos de disponibilidad, mantenibilidad, se puede:
Detener el sistema (más fácil determinar causa)
Registrar y continuar a partir de un estado seguro
reparar el daño causado por la falta
cambiar el sistema para eliminar la falta
Tolerancia a Faltas:
aislamiento del daño causado por la falta
prevenir que la falta se convierta en falla
basada en la predicción de las ubicaciones de las faltas y definición de caminos alternativos de operación

5. Técnicas para Mejorar el Diseño
Reducir Complejidad
Diseño por Contrato
Prototipado del Diseño
Análisis de Arbol de Faltas

Reducir Complejidad (1)
10
9
8
7
6
5
4
3
2
1
20
25
30
35
Complejidad del Diseño del Sistema
Faltas por mil lineas de código

Reducir Complejidad (2)
Generalidad de la solución
con menos componentes más simples resolver el problema
nivel de abstracción
Adaptabilidad de la solución
cubrir con una solución distintos problemas particulares

Diseño por Contrato (B.Meyer)
interacción entre componentes basada en contrato entre un cliente de un servicio y un proveedor del mismo
contrato define:
obligaciones del cliente-requisitos del servidor (precondiciones)
beneficios cliente-compromiso servidor (post-condiciones)
si un servidor recibe un requerimiento que no cumple las precondiciones, no está obligado a nada
podría abortar la ejecución, entrar en ciclo sin fin, etc.
internamente cada componente tendrá ciertas restricciones de consistencia (invariantes)
tratamiento de excepciones
si un servidor no puede cumplir un servicio, debe levantar una excepción (la que debe ser tratada por el cliente)

Prototipado de Diseño
Brooks (1975) recomienda construir un sistema, tirarlo y construirlo de nuevo para aprovechar en el segundo el aprendizaje de los errores cometidos al construir el primero
Construir una parte del sistema para evaluar factibilidad /riesgos
prototipo desechable
evolutivo
herramientas RAD (Rapid Application Development)
Mejora la comunicación en el grupo y con el cliente

Análisis del Arbol de Faltas
Ayudan a descomponer el diseño para identificar situaciones que podrían generar una falla
árbol lógico desde el efecto a las posibles causas
and
Modo llenado activo
Sistema de enfriamiento
desbordado
or
falla
Válvula
abierta
trancada
Pueden
ocurrir
ambos
Timeout
falla
Falla
Sensor
Deben
ocurrir
ambos
Evento
básico

Análisis del Arbol de Faltas
G3
G1
G2
G4
G5
A1
A2
A3
A4
A5
G1
G2
G3
{G4,G5}
{A4,A5}
{A1,G5}
{A2,G5}
{A1,A3}
{A1,A4}
{A2,A3}
{A2,A4}
Conjunto de Corte
Arbol de Faltas

6. Validación del diseño
Evaluación y validación del diseño
Técnicas para validar y verificar

Evaluación y Validación del Diseño
Validación: asegurar que el diseño satisface todos los requerimientos

Verificación: asegurar que incorpora características de un buen diseño

Técnicas para Validar y Verificar
Validación Matemática
Medir la Calidad del Diseño
Comparar Diseños
Una Especificación, Varios Diseños
Tablas Comparativas
Revisiones de Diseño
Preliminar
Crítica
De Programas

Validación Matemática
Prueba que el diseño es correcto
Demostrando que:
Si el conjunto de entradas se formula correctamente, es transformada correctamente en las salidas esperadas
El proceso termina sin fallar.

Medir la Calidad del Diseño
Medir el diseño de alto nivel, incluyendo cohesión y acoplamiento

Medir la complejidad de cada componente y de la relación entre componentes

Comparar Diseños
Una Especificación, Varios Diseños
Generar varios diseños para la misma especificación basados en diferentes estilos de arquitectura
Decidir cuál es el más adecuado para el propósito del sistema
Tablas Comparativa (ejemplo):
Facilidad para cambiar algoritmos
Facilidad para cambiar la representación de los datos
Facilidad para cambiar las funciones
Desempeño (tiempo de respuesta)
Facilidad de reuso

Revisiones de Diseño
¿Para qué?
Cuanto antes encontremos un problema, en menos lugares deberemos buscar la causa y corregirla.
Hacer todas las preguntas para asegurar que el diseño cubre todo lo necesario (listas de comprobación)
Preparación
Definir Participantes
deben saber qué se espera de ellos y recibir la documentación con antelación (posiblemente con breve charla)
Roles especiales:
Moderador: para que la reunión sea productiva
Secretario: para registrar los problemas y de las acciones a tomar
Acciones posteriores (Verificar que se cumplan)

Revisiones de Diseño
RD Preliminar (Al definir la Arquitectura)
cliente, usuario
analistas, diseñador sistema, otros no involucrados
moderador, secretario
RD Crítica (Técnica, previa al diseño detallado)
analistas, diseñador sistema, otros no involucrados
Diseñadores de programas
moderador, secretario
RD de Programas (Técnica, previa a la codificación)
analistas, diseñador sistema, otros no involucrados
Diseñadores de programas
Programadores
moderador, secretario

7. Documentando el Diseño
Un producto importante del proceso de Diseño es un conjunto de documentos que describen el sistema a construir.
Referencia Cruzada a los Requerimientos
Es la solución del problema